The “client-server” systems, widely used in the computer networking world, first appeared in cockpit avionics at the beginning of the new millennium. Cockpit avionics should be understood to cover all the electronic and computer means that make it possible to process, to display, to control and to modify the information necessary for the piloting and the navigation of an aircraft and more generally for the accomplishment of the mission of the aircraft during a flight.
The ARINC 661 standard provides a standardized framework for the implementation of these computer architectures in aeronautics. The components of such a system are, primarily:                a graphical server providing a capacity to plot basic graphical objects from prompts received in the form of requests or commands coming from the crew or from the “clients”. This server corresponds to the “cockpit display system”. It comprises the display units, human-machine interfaces, the database of the characteristics of the “widgets”, or “widget library”, and an “ARINC 661” format dialogue protocol. A “widget” is a software unit associated with a graphical representation;        clients called “user application”, or “UA” in the ARINC 661 standard executing the operational functions and sending requests to the server to display the information.        
The graphical server offers the capacity to process actions that an operator, in this case the crew, wants to initiate on a client. In a client-server architecture, the operational intelligence is therefore located in the clients. The server simply executes the requests from its clients without having any operational knowledge thereof. Conversely, in the conventional avionics architectures, the operational intelligence is situated in the cockpit equipment elements which therefore control the functional content of what they display.
FIGS. 1 and 2 describe the functional streams of an interactive server on initialization of the system and while the system is being used. An interactive application or client sends, on initialization of the system, in the form of “instantiation” commands, the definition of the interactive pages which are stored on the server in the form of the model of the “widgets”. A “widget” should be understood to be a software unit associated with a graphical representation and a behaviour presented on the cockpit display units, also called “DU”. The widgets enable the crew, by means of a control medium, to give instructions to the aircraft control system and to receive information. From this model, as can be seen in FIG. 2, graphical commands are generated cyclically and sent to the graphical machine. The model of the widgets can be modified either by the sending of a command from the application under its own initiative, or by the action of a user on the control medium which also generate a response from the application in the form of a command. In FIG. 2, the path taken by the commands from the media is represented by bold-line arrows.
By way of examples, the control media are keyboards, computer “mice”, “trackballs”, touch screens or dedicated control stations, for example of “KCCU” (keyboard cursor control unit) type. The widgets are conventionally pop-up menus, graphical buttons, numerical input fields, “combo-boxes” and more generally cover all the graphical interaction means.
In aeronautics, there are a certain number of so-called critical functions which have to be able to be managed by a “client-server” system. A critical datum or function should be understood to be a datum or a function whose unexpected modification or untimely activation by a piloted system may result in a catastrophic scenario or an accident for the aircraft. The events to be feared fall into two categories, human errors on the one hand, and malfunctions leading to a problem of non-integrity of the functions or of the data or even an untimely activation on the other hand.
The human errors involve an accidental or untimely action on the part of the operator, for example an accidental click on a widget.
The problem of integrity concerns three types of events:
an interaction of the user who obtains a good visual feedback, but for which the associated command is not processed or sent without the user being aware of it. It is therefore essential to guarantee that a user request deriving from an action on a graphical element is taken into account and that the associated processing is carried out;
a user interaction which does not result in any visual feedback, but for which the associated command is processed or sent without the user being aware of it. It is therefore essential to ensure the consistency between a user interaction and the associated visual feedback;
an unexpected modification of the structure of the model of the widgets or of the attributes of this model.
For dependability, it is necessary to put in place an integrity check for the operational function in the cockpit system. One of the techniques commonly implemented is “feedback” which consists in verifying, by a inverse computation, the consistency of the parameters displayed with the parameters supplied to the system. The mathematical foundation of this mechanism is based on the fact that the composition of a function by its inverse is equal to the identity function (F° F−1=identity). Thus, if it is possible to find the inverse function F−1 of the display function F of a critical parameter p, it is sufficient to verify that F(F−1(p))=p to guarantee that the function F has indeed been executed. From a system point of view, in order to guarantee that there is no failure that might affect both the function and its monitoring, the functions F and F−1 must be sufficiently segregated. Specific segregation or “partitioning” mechanisms are thus implemented in the host structure of each computation core in order to prevent a possible corruption from a failure of a first function affecting a second function (in particular the monitoring function). FIG. 3 illustrates the “feedback” control mechanism for a display subsystem conventionally comprising:                means for acquiring information arriving from a sensor which may be an inertial unit, for example;        means for processing said parameters, and;        graphical generation means, the assembly forming a function F for processing the parameters from the sensor.        
This subsystem includes a monitoring subsystem which, in parallel, acquires the information coming from the sensor and compares the information with the data deriving from a function F−1 which recomputes, from the graphical information, the value of the parameters coming from the sensor.
Consequently, a “client-server” system that can be used, for example, for aeronautical applications, for critical functions must allow:
the display on the “DU”s of critical data sent in the form of commands by an interactive application hosted on a client. The display of engine parameters sent by the appropriate computers will notably be cited;
the use of the interactivity on the “DU”s to check critical functions. As an example, it is desirable for the crew to be able to modify the state of a pump of the fuel management system in a safe manner.
The introduction of the client-server architectures into the critical systems poses the problem of the implementation of the integrity check. The current feedback mechanism covering all of the functional subsystem cannot be made available directly on the server on the one hand and the client on the other hand.
Furthermore, the user interactivity, that is to say the launching of commands by the crew from the graphical interface, is not currently implemented for critical functions or else is implemented using additional means which are highly limiting in terms of human factors. Currently, to avoid these problems, the “client-server” architectures are implemented in non-critical embedded systems.